1. Field of the Invention
The present invention is related to database security. More specifically, the present invention is related to a method and an apparatus for managing security policies for databases in a distributed system
2. Related Art
Many commercial database systems provide access controls that limit the operations that can be performed by various users. For example, a user who correctly enters a user identification (user ID) and a password is typically allowed to access the database system as an authorized user. One or more privileges are assigned to each authorized user, wherein a privilege defines specific operations the authorized user may perform on database objects. For example, a user may have a privilege that allows the user to read all data in a table, but does not allow the user to write data to the table.
Note that database operations include data manipulation operations and database definition operations. Data manipulation operations can include adding a row, deleting a row, and modifying contents of a row, among others. Database definition operations can include adding a table, adding a column to a table, and adding an index for a table, among others. Other database operations can include logging on to the database system and establishing a communication session with a database server.
Access controls provided by early commercial database system frequently did not satisfy access control requirements for some organizations. For example, once a user was granted access rights to a database, the user had access to all tables in the database. This type of access control does not support security policies, such as multi-level security policies. For example, information in a database containing information about military units and their capabilities is typically subject to a multi-level security policy. The multiple levels include “unclassified,” “confidential,” “secret,” and “top-secret.” According to this policy, information classified as secret may be accessed only by users who are cleared through the secret level or higher. Hence, information that is secret may be accessed by a user cleared through secret and top-secret levels, but not by an uncleared user or a user cleared through only the confidential level.
In order to implement a multi-level security policy in a system that provides conventional access controls, data for each different security level must be kept in a separate database. Placing data in separate databases based on security level increases storage space requirements, greatly decreases efficiency of many database operations, and often leads to inconsistencies between copies of the same data stored in separate databases.
One approach to providing the access control required by a multi-level security policy is to store data with different security levels data in different tables of the same database. In some cases, the tables are stored in separate files with access to the files controlled by the operating system. Placing data in separate tables and files based on security level is still very inefficient because database operations have to access multiple tables and files and multiple copies of the same data may be stored in the separate tables and files leading to the same problems encountered when using separate databases.
In some database systems, information associated with different security levels is contained in a single database object. For example, access controls can be applied separately to each row in a table. However, this type of system still has drawbacks.
One drawback is that typically only one “security policy” is provided for the database system, yet one security policy may not meet the needs of all users. For example, the multi-level policy does not suit some commercial applications that need to control access to corporate data based on levels within the corporation's hierarchy. In another example, the multi-level policy may not match file access controls of a UNIX operating system, which provides user, group, and world permissions separately for reading and writing files. One user may want to apply the corporate hierarchy levels, another user may want to apply the UNIX operating system controls, and a third user may want to apply a combination of both on the same data. Using conventional approaches, three different database servers would have to be configured to support these three different policies.
Another drawback is that any modification to the security policy typically requires changes to instructions scattered throughout the database system. This makes the task of managing the security policy difficult, costly, and prone to error, and can result in unanticipated and undesired side effects. For example, programmers responsible for modifying the code of a database server to implement a single change in a security policy may make modifications to seven distinct places in the code, without realizing that modifications are also required at two other locations. By failing to make changes in all locations, the database server may fail to operate properly, and may even operate in a manner directly contrary to the policy change for which modifications were being made.
Furthermore, it is often desirable for a security policy to be added to an existing database server without taking the database server offline, so that users of a database system are not prevented from continuing to perform database operations while the change in security policy is taking place.
Database designers have addressed the above problems by using label-based security policies. These label-based security policies are described in the related application entitled, “Techniques for Adding Multiple Security Policies to a Database System,” having Ser. No. 10/006,543, and filing date 30 Nov. 2001, which is incorporated by reference above.
Briefly, these label-based security policies operate by adding label columns into database tables. These columns contain attributes that specify what is required to access data within the associated row within the table.
Currently, implementations of these label-based security policies and authorizations are defined and managed separately for each database. This places a large burden on database administrators who are often required to configure many databases with the same security policies. Furthermore, management of label authorizations often requires the same modifications of authorization to be performed on multiple databases scattered throughout an enterprise. In a large enterprise with numerous user accounts and databases, an administrator may not be able to make all of these changes in a timely manner which leads to increased security risks.
Hence, what is needed is a method and an apparatus for centralized management of security policies for multiple databases in a distributed system without the above described problems.